TOP

top is the default, built-in real-time system monitor on nearly every Linux distribution. It shows CPU usage, memory and swap pressure, load averages, and a live process table. In WordPress VPS operations, top is a reliable fallback when htop/btop are unavailable, and it is especially useful during emergency SSH sessions on minimal systems.

Background and history

Early Linux performance triage relied on lightweight tools that could run under heavy load and on minimal installations. top became the standard interactive process viewer because it was small, dependable, and broadly available. While newer monitors provide richer UIs, top remains a foundational tool because its output and key bindings are widely known and available by default.

Adoption and where it’s commonly used

top is commonly used on:

• Minimal VPS images and rescue shells
• Production servers where only core packages are installed
• Incident response sessions where speed and availability matter
• Daily sanity checks on CPU, memory, and runaway processes

Maintained by

• Maintained by the Linux distribution community as part of standard system utilities.

Best when to use

• You need immediate triage on a server with minimal tooling.
• The server is heavily loaded and you want a low-overhead monitor.
• You need a universal command that behaves similarly across systems.
• You need to quickly identify top CPU/memory consumers.

Not suitable when

• You need rich visualization of I/O and network trends (use btop or dedicated I/O tools).
• You need convenient filtering, tree views, or interactive configuration (use htop).
• You need long-term historical insight (use a metrics stack and dashboards).
• You need automation-friendly output (use ps, top -b, pidstat, sar).

Compatibility notes

• top is available on most Linux systems, but output can vary slightly by distro and version.

• CPU reporting may differ on virtualized hosts due to steal time.

• Process names differ by WordPress stack:

  • OpenLiteSpeed often uses lsphp
  • PHP-FPM may appear as php-fpm, php-fpm8.x, and pool workers
  • MariaDB typically appears as mariadbd, MySQL as mysqld

Launch and exit

top

Exit with q.

Useful launch variants:

# Show only processes for a specific user (example: common web user)
top -u www-data

# Start with a faster refresh interval (seconds)
top -d 1

How to read the header

The top header contains the most important health signals for WordPress operations.

Load average

top shows three load averages (commonly 1, 5, and 15 minutes). Compare load to CPU core count.

• If sustained load is consistently higher than the number of CPU cores, the system is likely saturated or bottlenecked.
• Load can increase due to CPU saturation and also due to I/O wait.

Load is not only CPU

High load with moderate CPU usage often indicates I/O bottlenecks (slow disk, heavy writes, database flushing). Correlate with I/O tools when needed.

Tasks

Tasks summarize how many processes are:

• Running (actively executing)
• Sleeping (waiting; often normal)
• Stopped
• Zombie (exited but not reaped)

A few zombies are usually not a crisis, but persistent zombie growth suggests a parent process issue.

CPU usage breakdown

Typical CPU fields:

• us (user): application CPU time (PHP, MySQL, compression)
• sy (system): kernel CPU time (networking, filesystem)
• id (idle): unused CPU time
• wa (iowait): waiting on disk I/O
• st (steal): time taken by hypervisor (virtualization contention)

WordPress patterns:

• High us: PHP/plugin work, DB queries, compression/backups
• High sy: heavy networking, firewall overhead, filesystem pressure
• High wa: storage bottleneck (DB writes, backups, slow disk)
• High st: noisy neighbors on shared virtualization or CPU oversubscription

Memory and swap

top shows RAM and swap totals and usage. Interpretation varies slightly by version (some show buff/cache separately).

Operational guidance:

• Focus on whether swap is increasing and whether the system is under memory pressure.
• Linux uses RAM for caching; low “free” RAM is not automatically bad.
• Swap growth correlates strongly with degraded WordPress performance.

Process table columns

Common columns in the process list:

Column	Meaning	Why it matters
	--
PID	Process ID	Used for correlation and safe intervention
USER	Owner	Helps identify web vs system jobs
%CPU	CPU utilization	Find hot processes quickly
%MEM	Percent of RAM used	Identify memory pressure sources
TIME+	Total CPU time	Persistent offenders accumulate time
COMMAND	Process name/command	Identify service and workload type

Additional fields depending on configuration:

• PR / NI: priority/nice level
• RES: resident memory in KB/MB (more actionable than VIRT)
• S: process state (R, S, D, Z)

Essential interactive keys

Inside top:

Action	Key
--
Sort by CPU	P
Sort by memory	M
Sort by time	T
Change refresh interval	s
Kill a process	k
Toggle per-CPU view	1
Toggle threads view	H
Help	h
Quit	q

WordPress daily workflows

1) Identify a CPU spike culprit

Steps:

1. Run top

2. Press P to sort by CPU

3. Look for common stack processes:

   • lsphp or php-fpm (PHP workload)
   • mariadbd/mysqld (database workload)
   • redis-server (cache workload)
   • tar, gzip, zip (backups/compression)

Typical interpretation:

• One PHP worker stuck at high CPU: stuck request, plugin loop, or expensive endpoint
• Many PHP workers moderately high: traffic spike, bot traffic, caching gaps
• Database high CPU: expensive queries, missing indexes, wp-cron loops

Safe follow-up checks (read-only first):

# Confirm which services are running
systemctl status php*-fpm 2>/dev/null || true
systemctl status lsws 2>/dev/null || true
systemctl status mariadb 2>/dev/null || systemctl status mysql 2>/dev/null || true
systemctl status redis 2>/dev/null || systemctl status redis-server 2>/dev/null || true

# Inspect current sockets to understand exposure and activity
ss -tulpen

2) Investigate memory pressure and swap growth

Steps:

1. Run top

2. Press M to sort by memory

3. Identify large memory consumers:

   • mariadbd/mysqld (buffers/caches)
   • redis-server (object cache)
   • many PHP workers (aggregate footprint can be significant)

Interpretation:

• If swap keeps increasing: memory pressure is ongoing and performance will degrade.
• If memory is high but swap stable and no OOM events: may be acceptable depending on workload.

3) Distinguish CPU-bound vs I/O-bound problems

Use CPU breakdown and load together:

Symptom	Likely bottleneck	What you’ll see in top
-		-
High %CPU and high us	CPU-bound	Processes at high %CPU, load rising
Moderate CPU but high load and high wa	I/O-bound	wa elevated, load rising, CPU not fully used
High st	Hypervisor contention	st elevated, performance inconsistent

If I/O-bound is suspected, validate with read-only tools:

# Lightweight snapshots
vmstat 1 5
iostat -x 1 3 2>/dev/null || true

4) Spot wp-cron storms

In top, look for repeated or persistent processes like:

• php wp-cron.php
• many short-lived PHP workers

Operational mitigation is typically:

• Disable pseudo-cron and schedule wp-cron via OS cron at a controlled interval.

Safe process intervention

Prefer controlled service operations over killing

If a service is malfunctioning, prefer service-level actions when safe and planned:

# Examples (verify the correct unit name on your system)
sudo systemctl restart php8.2-fpm 2>/dev/null || true
sudo systemctl restart lsws 2>/dev/null || true
sudo systemctl restart mariadb 2>/dev/null || true
sudo systemctl restart redis 2>/dev/null || true

Kill a process from inside top

1. Press k
2. Enter the PID
3. Prefer 15 (SIGTERM) first for graceful shutdown

Only use 9 (SIGKILL) when:

• The process is confirmed non-critical, or
• It refuses to terminate and is actively harming stability

High-risk targets

Avoid killing sshd, mariadbd/mysqld, your active web server (lsws/nginx/apache2), or PHP-FPM master processes during normal operations. Use console/serial recovery access for emergency changes and prefer controlled restarts.

Filtering and focused views

Show only one user’s processes

Common WordPress web user examples:

top -u www-data

OpenLiteSpeed environments may run workers under nobody:

top -u nobody

Show per-core CPU usage

Inside top, press:

1

This helps detect:

• Single-thread limits (one core pegged while others idle)
• Whether load is evenly distributed

Show threads

Inside top, press:

H

Useful for:

• Understanding worker/thread behavior in PHP and databases
• Confirming whether work is spread across threads or blocked

Go-live and daily health checklist

Check	Target	What to do if it fails
		--
Load vs core count	Sustained load at or below core count	Identify CPU vs I/O; tune caching; reduce cron; scale
CPU breakdown	Low wa and low st under normal load	Investigate disk (if wa) or hypervisor (if st)
Memory usage	Stable with headroom	Reduce allocations, tune workers, add RAM
Swap	Minimal and not trending upward	Reduce memory pressure; tune DB/Redis/PHP; add RAM
Top processes	No persistent runaway processes	Identify culprit, inspect logs, intervene safely

Troubleshooting matrix

Symptom	Likely cause	Safe next step
	-	--
CPU stays high	Plugin loop, heavy endpoint, bot traffic	Sort by CPU, check access logs, validate caching
High wa	DB writes, backups, slow storage	Correlate with I/O tools, reschedule backups, tune DB
Swap rising	RAM pressure from DB/Redis/PHP workers	Reduce allocations, tune worker counts, add RAM
High st	Hypervisor contention	Consider instance type change or dedicated resources
Zombies increasing	Parent not reaping children	Restart the parent service during a safe window

Quick lab: observe controlled load

Run only on non-production or during a maintenance window.

Generate load:

ab -n 1500 -c 50 https://yourdomain.com/

Monitor:

top

Observe:

• Whether CPU becomes saturated and which processes consume it
• Whether wa spikes (storage bottleneck)
• Whether swap begins to increase (memory pressure)
• Whether load remains elevated after the test

Load testing risk

Synthetic load can cause downtime and trigger rate limits or security bans. Use controlled concurrency and a maintenance window.

Cheat sheet

Goal	Command / Key
--	--
Start top	top
Quit	q
Sort by CPU	P
Sort by memory	M
Per-core view	1
Show threads	H
Kill a process	k then PID (prefer SIGTERM 15)
Change refresh interval	s
Filter by user	top -u www-data